I kept this part of the code intentionally, because I would argue that having access to the access token within the request(-session) is an important feature. I think the most important use case is to be able to use the access token for subsequent requests on behalf of the user to other services.

If you didn't have the access token from here, how would you implement it otherwise in the application (not this library)? I'm not convinced that this package should handle anything other than authentication (not authorization or integration with Azure web services).

Thanks for you swift reply!

I kept this part of the code intentionally, because I would argue that having access to the access token within the request(-session) is an important feature. I think the most important use case is to be able to use the access token for subsequent requests on behalf of the user to other services.

If you didn't have the access token from here, how would you implement it otherwise in the application (not this library)? I'm not convinced that this package should handle anything other than authentication (not authorization or integration with Azure web services).

You would also have to carry out one of the OAuth2 authentication flows to retrieve an access token and thus authenticate the users, e.g. using the MSAL library (https://github.com/AzureAD/microsoft-authentication-library-for-python) in case of Azure AD. But this is exactly what you already do within the library and would mean duplicating the whole token exchange logic etc.

I think the point here is not yet about authorisation or integration yet as exposing the access token is simply the "source of truth" for authenticating the user. This is also what the library uses internally to derive the exposed user information.
However, in some cases (e.g. when one wants to forward the authentication to some other service) the exposed information, which you extract from the token, is not sufficient (e.g. because it is not signed and not verifiable by an external service).
Authorisation (i.e. if you are actually allowed to do something) and integrating with other services would still be out of scope for the library but would require to have this "pure" authentication available in some cases.

The only reason that I can come up with to not store the token is to avoid allowing the library to do more with the API as a part of the library. But I don't think that's a good enough reason to make things more difficult for users. That said, I'm okay with storing it. cc @JonasKs

And now I'm having second thoughts around security concerns. If we start storing the access token in the session, we're making a choice for all users of the library. That shouldn't be something we decide for users unilaterally. Additionally, we can't use the session is the user is using cookie-based sessions.

The changes I'd like to see are:

• Move as much of the new changes to the middleware and out of the backend
• Only store the token information in the session if the refresh token middleware is being used (not sure the best way here)
• Prevent the library from storing tokens in the session if cookie based sessions are being used
• There needs to be some documentation

Thanks for the feedback!

I have some vacation coming up but will look into it again once I am back.